-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Nan2 #72
Conversation
|
||
target->Set(NanNew<String>("StringPrep"), t->GetFunction()); | ||
target->Set(Nan::New<String>("StringPrep").ToLocalChecked(), t->GetFunction()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
correct but you should use Nan::Set(target, Nan::New<String>("StringPrep").ToLocalChecked(), t->GetFunction());
now for max-compatibility
+1 Need this very much. Looking to moving to Node 4.1.0. |
👍 |
👍 as well! Thank you for your efforts! |
@rvagg is usually very helpful with |
The Nan2 support that @erulabs has started is looking pretty good so far. |
@@ -43,11 +43,11 @@ class StringPrep : public ObjectWrap { | |||
|
|||
static NAN_METHOD(New) | |||
{ | |||
NanScope(); | |||
Nan::HandleScope scope; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can be removed from inside all NAN_*()
methods
You rule @rvagg, thanks! |
NanScope(); | ||
Local<FunctionTemplate> t = NanNew<FunctionTemplate>(New); | ||
Nan::HandleScope scope; | ||
Local<FunctionTemplate> t = Nan::New<FunctionTemplate>(New); | ||
NanAssignPersistent(stringprep_constructor, t); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
../node-stringprep.cc: In static member function ‘static void StringPrep::Initialize(v8::Handle<v8::Object>)’:
../node-stringprep.cc:24:50: error: ‘NanAssignPersistent’ was not declared in this scope
NanAssignPersistent(stringprep_constructor, t);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
stringprep_constructor
needs to be declared as a Nan::Persistent
now (instead of just Persistent
, i.e. v8::Persistent
) and then you use stringprep_constructor.Reset(t)
here
{ | ||
Nan::EscapableHandleScope scope | ||
size_t destLen = str.length() + 1; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
../node-stringprep.cc: In member function ‘v8::Local<v8::Value> StringPrep::prepare(v8::String::Value&)’:
../node-stringprep.cc:115:5: error: expected initializer before ‘size_t’
size_t destLen = str.length() + 1;
Hey @sonnyp looks like a missing semicolon on line #114 The remaining issue seems to be how we return the value (lines 228 & 279): Local result = Nan::New(dest, destLen).ToLocalChecked(); This passes tests, but appears to break the unicode/ascii conversion. I tried a handful of ideas without much results. +1 to big big thanks to @rvagg 💃 |
|
Yeah - it should be a Local for sure, which builds properly, but breaks the actual tests. I get the feeling that something here is breaking our unicode/ascii converstion |
I wonder if we can reach out to the original authors of node-stringprep.cc and see if they have some advice for us since it seems like we've hit a dead end :( |
Actually @astro is the original creator AFAIK, I've just been keeping it ticking over. I'm afraid native module binding isn't something I'm familiar with. |
As far as node-xmpp is concerned I don't think we should spend much time on node-stringprep. RFC 7622 deprecates the use of stringprep see https://github.com/node-xmpp/JID/issues/1 I have made a standalone and stringprep-free module for JID at https://github.com/node-xmpp/JID and plan to use it in node-xmpp-core see https://github.com/node-xmpp/node-xmpp-core/pull/76 . (Somehow all original tests passes without stringprep) I understand it's not fully compliant but neither is node-xmpp-core JID anyway ( + other issues such as memory leaks and native module burden). I plan to work on RFC 7622 compliance next. |
Tracking: nodejs/node#2798 |
Fixed by #79 |
WIP; could use some help